1. Field
The invention relates to a computer communication system for communicating via public networks in general, and in particular to a method of encapsulating and encrypting data to ensure confidentiality combined with reliable transport features within so called Virtual Private Networks (VPN).
2. Background
Computer networks have become a central part of the corporate infrastructure in business organizations of all sizes. A challenge that continues to face organizations is how to connect remote users who need to access their email and internal servers while away from the office in a most reliable, flexible and cost-effective manner.
Virtual Private Networks (VPNs) are used to connect people like home workers or sales personal while travelling with their corporate network. With VPNs one can create a secure private network utilizing some other public network such as the public Internet, which might be less secure.
For these VPNs network protocols like IPSec, PPTP or L2TP are used. These protocols will be discussed in greater detail in the discussion below.
In the following the computer initiating a VPN connection is referred to as a VPN client. The computer responding to the initiation of the VPN connection is referred to as a VPN server. A VPN server is typically placed in an organizations DMZ (demilitarized zone) which is a network that is separated from the internal network and the public network by the use of firewalls.
To better understand the background of the invention also the prior art is to be explained in more detail referring to FIG. 1-5, the contents of which is presented in the passage “BRIEF DESCRIPTION OF THE DRAWINGS” below.
FIG. 1 is a diagram that shows the major functional components of a VPN. The system comprises a computer that works as a VPN client 1 which is physically connected to a remote network 2. This remote network 2 is separated from the public Internet 3 by the use of a firewall 4.
At the other end there is a VPN server 5, which is physically connected to a network segment that belongs to a DMZ 6. The DMZ 6 is part of a firewall system 7 which separates the DMZ 6 from the outside public Internet 3 and the inside corporate network 8. Inside the corporate network 8 there is a number of servers 9 to which the VPN client 1 might wish to connect.
Personal computers and notebooks used today are equipped with operating systems like Microsoft Windows, MAC OS or Linux. In parts of these operating systems, clients for Virtual Private Networks are already included. But initially these VPN clients are not ready configured for use. At least they need information about a specific VPN server as a remote station in the corporate network.
In case other VPN clients, i.e. VPN-client software that is not integrated into the operating system, are used, they need to be manually installed and configured. This installation work often requires administrator rights. Due to the fact that most computer user do not have such rights, the installation of said VPN-client software cannot be done by all users themselves. In case of big companies there may be thousands of VPN-clients each have to be supported by the company IT staff which service may be very expensive and time-consuming.
Today most of the VPN clients, which are built into the operating system, use protocols like PPTP or L2TP. PPTP, the “Point-to-Point Tunnelling Protocol” is defined by the Internet Engineering Task Force (IETF) in the document RFC 2637. As is illustrated in FIG. 2 PPTP encapsulates VPN data inside PPP packets, which are then further encapsulated in IP datagrams for transmission over a transit IP network such as the public Internet. PPP, the “Point-to-Point Protocol” is defined in RFC 1661.
The PPTP uses a TCP connection (TCP Port 1723) for creation and maintenance of a PPTP tunnel VPN data are encapsulated in a header of the type GRE, Generic Route Encapsulation.
VPN clients built into the operating system may alternatively use the L2TP, the “Layer Two Tunnelling Protocol” (see RFC 2661). FIG. 3 illustrates the L2TP-Encapsulation without encryption. As becomes apparent from the drawing L2TP also encapsulates the data within PPP packets and adds a specific L2TP header. L2TP packets are sent via UDP Port 1701.
As is shown in FIG. 4 L2TP may also be secured by an IPSec encryption, which is defined in RFC 3193 “Securing L2TP using IPSec”. When L2TP is secured via IPSec, the IPSec Key-Exchange ISAKMP (“Internet Security Association and Key Management Protocol”—defined in RFC 2408) is handled over UDP Port 500. The L2TP data encrypted with IPSec uses IP packets of the type ESP (Encapsulated Security Payload—RFC 2406).
The encapsulation methods described above (IPSec, PPTP or L2TP) are well known for persons skilled in the art for years, but they cannot be used by the VPN-clients everywhere. There are many locations, where a user may want to have a connection to its remote corporate or home network, but these locations might be connected to the public Internet through a firewall.
In most of the cases these firewalls block all traffic from the internal networks to the public Internet with the exception of outgoing connections for some specific protocols like HTTP, the “Hypertext Transport Protocol”—TCP Port 80 and HTTPS, the “Hypertext Transport Protocol Secure”—TCP Port 443. HTTP and HTTPS are not blocked, since these protocols are usually used for “browsing” the Internet. The security policies of most companies allow using said protocols to communicate with destinations in the public Internet.
HTTPS means HTTP over SSL with the standard TCP port 443. SSL, the “Secure Sockets Layer” is a cryptographic system which provides an encrypted data stream for secure communication on insecure networks. For this purpose SSL uses a public key infrastructure with public and private keys. The public key is known to everyone but the private key is only known to the recipient. In this way the sender can encrypt a data message by use of the recipient's public key and only the recipient who holds the private key can decrypt the message.
These are all techniques which are well known in the art.
Current firewall systems may also contain proxies, which have to be passed when sending data from the internal network to the public Internet. Protocols for these proxies include HTTP or the SOCKS protocol (see RFC 1928). The Web-Browsers internal to such locations have to be configured, so that traffic to the public Internet uses the aforesaid protocols to get a path through the firewalls via the proxies.
Because HTTPS and SSL can be used at most locations with Internet access, another type of VPN has emerged, the so-called SSL-VPN. In most cases SSL-VPNs use TCP port 443, which is normally used for encrypted HTTPS-connections to the public Internet and therefore traffic destined to TCP port 443 is not blocked at the firewalls.
Now there are two different kinds of SSL-VPN depending on the need of a specific client. The first type of SSL-VPN does not need specific client software and the traffic only goes to (HTTP) Web-Servers. The access techniques used for this type of SSL-VPN work as follows:
Before a client application may access resources on the corporate network the user has to start a browser application and has to navigate to a specific web page which acts as an entry point to the VPN. After authentication the user has access to the VPN and specific applications running on the client computer may connect to resources on the corporate network. This technique is also known as the “application proxy” model.
The second type of SSL-VPN works with client software. For this second type there are those SSL-VPN clients which just listen on the “localhost” address. “Localhost” is a special IP-address which always translates to the so-called loopback IP-address (127.0.0.x), which is the local machine itself. Such clients can also be downloaded from a Web-Server and need no local installation. This solution, however, has limited usability, because not all the traffic can be routed over aforesaid localhost address. Reason for this is the fact that special configuration is necessary and also that often network address translation (NAT) is in use. This means the IP-addresses are translated into other IP-addresses, and these are no longer valid when localhost is used as an intermediate gateway.
Clients for SSL-VPN can also be installed into the operating system of the VPN-client machine. In this case the client uses drivers to the operating system, like virtual adapters. All these software parts have to be installed which again means the user has to have administrator rights. But with these drivers, transparent access to all target computers in the corporate network is possible, and as an additional advantage one can reach the remote VPN-client from the corporate network. When the term “transparent access” is used here, this means that all network packets with an IP-header can be forwarded between the client and the corporate network and vice versa. This includes such protocols as TCP, UDP, ICMP and so on.
Summing up the above discussion, with the current technology, if a user needs really transparent access to the corporate network, software with drivers has to be installed on his client computer.
There is another problem that exists in the connection with software including drivers. Drivers are very difficult to develop, and so most available drivers are not error-free and often cause problems.
Now there is a newer form of SSL-VPN deployed by Microsoft, which becomes apparent from FIG. 5. It is called SSTP, the “Secure Socket Tunnelling Protocol”. This protocol has features that allow traffic to pass through firewalls that block PPTP and L2TP/IPSec traffic. SSTP provides a mechanism to encapsulate PPP traffic over the SSL channel of the HTTPS protocol. By this way traffic will flow through TCP port 443, a commonly used port for Web access. The use of PPP allows support for strong authentication methods. SSTP is integrated in certain Microsoft® operating systems beginning with “Windows® Vista® SP1” or “Windows® Server 2008 SP1”. However, also with SSTP there is the need to manually configure the SSTP-software at the VPN client computer.
Again summarizing the above statements, with SSL-VPN you can avoid some of the problems which exists in certain traditional VPN environments but there are still other problems to solve such as the need of SSL-VPN solutions to install and configure software at the VPN-client computer, which is not possible under certain circumstances or at least very time-consuming and expensive if a vast number of clients exists.